ETSI ISG NIN ran from 2020 until 2024. The following is an archived copy of its Technology page.

Introduction

The Industry Specification Group (ISG) on Non-IP Networking (NIN) has been set up to standardize a digital communications technology fit for the 21st century.

Our vision is a much more efficient system that is far more responsive to its users.

Networking for the age of virtualization

The TCP/IP suite of network protocols is now over 40 years old and was designed for different requirements than the networking of the 2020s. This raises addressing, mobility, performance, and security issues; and efforts to mitigate them have required significant effort, energy, and cost, and added significant complexity.

With the increasing challenges placed on modern networks to support new use cases (some of which require ultra-low latency) and greater connectivity, Service Providers are looking for candidate technologies that may serve their needs better than the TCP/IP-based networking used in current systems.

ISG NIN is standardizing networking technology which natively meets 21st-century requirements such as mobility, security, privacy, efficient use of spectrum, and ultra-low latency. The title, Non-IP Networking, emphasises that the technology is not dependent on IP packet formats or protocols; however, it supports the TCP/IP suite as well as other systems such as Information Centric Networking. An application wishing to access a service (or some content) identified by a URL, or a virtualized network service, can request it directly instead of first having to find an IP address that identifies a location where the service is provided.

Software-Defined Networking (SDN) can provide a flow control overlay for IP networks. Like SDN, ISG NIN’s Flexilink technology recognizes that most packets are part of a “flow”, and most of the decisions the system has to make are per-flow rather than per-packet. For instance, the “next hop” from a switch towards the destination will be the same for every packet on a flow; and packets carrying a live audio or video stream will arrive at regular intervals and require to be forwarded promptly, whereas packets from other applications with less-stringent latency demands can be queued. Flows can easily be redirected around faults or when a mobile device moves to a different cell.

In the case of SDN, the flow is identified by searching a “flow table” for a match with information that is scattered over different parts of the packet header, which involves significant per-packet processing. Flexilink packets, on the other hand, simply contain a “label” which points directly to the flow table entry.

IP packet formats are the same over the whole network; this is why, 30 years after IPv6 was first proposed, much Internet traffic is still using IPv4. Flexilink packet formats are appropriate to the physical layer technology of each link, for instance a higher-capacity link will support more flows. Introducing a link with a new format does not require any change to the rest of the system, and migration from IP to Flexilink can be done in stages as life-expired equipment is replaced.

Achieving ultra-low latency

Recognizing that networks will carry an increasing amount of time-critical traffic – not only live audio and video but also applications promised for 5G such as industrial automation and remote surgery – and that traditional store-and-forward packet networks struggle to reliably achieve the low-millisecond latencies that some of these applications require, Flexilink supports two kinds of flow. “Basic” flows provide the best-effort service with queues that is traditional for packet networks, while “guaranteed” flows provide a service for time-critical traffic. The two services can be multiplexed together so that all the capacity not occupied by guaranteed service data (including capacity reserved but not used) is available to the basic service.

To provide the lowest latency, the guaranteed service can be implemented in a way that is more like the “routers” that switch point-to-point audio and video. It can also be carried over other technologies such as TSN (Time-Sensitive Networks); the latency (which will be higher in that case) is reported in the control plane messages that set the flow up.

Our Role & Activities

We have identified a number of technical issues with the current (TCP/IP-based) technology which prevent it delivering the required levels of service without excessive complexity or, in some cases, at all.

What does this mean for the user?

Elimination of delays in packet forwarding equipment will make conversation more natural, especially in conference calls. A performer’s sound can be sent across the network to be mixed with other performers’ and returned to their headphones. Applications such as remote surgery become possible.

Privacy is improved: devices do not need to have IP addresses, and a server does not need to know a client’s address or location in order to reply to its request. Before any exchange of data takes place the server can require as much or as little authentication of the client’s identity as is appropriate to the application. It will be much easier to discover where your device is sending data to.

Downloads will be faster, and there will be less “buffering delay” when watching streamed content. New business models can be explored based on improved identification of content and quality auditing.

What does it mean for the operator?

The whole system becomes much simpler and therefore cheaper to build and to operate. Many middle-box functions, such as address translation, firewalls, header compression, and transport-layer optimisers, are eliminated or incorporated into the control plane procedures. Mobility is supported natively instead of needing tunnelling layers to be added.

The service for media streams provides multicasting and ultra-low latency (typically less than 10µs per hop) as standard. As well as live broadcasting (such as of sporting events) it can be used to distribute recorded content to local caches and to distribute software updates.

Many of the protocols needed by current systems, such as DNS, ARP, SIP, SDP, and RSVP, are incorporated into the control plane procedures. This, along with a dramatic reduction in packet header sizes, reduces the amount of capacity on the air interface that is taken up by protocol overheads.

The forwarding plane can be implemented entirely in logic (hardware), and thus needs much less power than is needed for per-packet processing by software. Simplified protocols and elimination of the need for header compression reduce processing power requirements further.

How do we get there?

The new technology can be carried over IP networks, and IP packets can be carried over the new technology. Thus, the new technology can be introduced incrementally, in the form of “islands” where internal traffic benefits from the new levels of service and there is seamless transition to the legacy technology at the edge. This can be done as part of the normal processes of expanding networks and of replacing end-of-life equipment.

An example would be where a new network is being built to support 5G: core, RAN, and MEC can be implemented with the new technology. When an application connects a socket to a service, the system can check whether that service is available at the edge and if so connect directly using the new technology. This check might need more information than would be provided in the DNS look-up used in legacy systems, e.g. to see whether a cached copy of a particular piece of content is available. Otherwise, the connection goes through the User Plane Function; much of the processing of legacy packet headers is transferred from the UE to the UPF, saving battery in the UE, and the amount of processing required in the UPF is similar to the NAT procedures common in today´s Internet access.

Participation in the Non-IP Networking Industry Specification Group is open to all ETSI members as well as organizations that are not members, subject to signing ISG Agreements. For information on how to participate please contact ISGsupport@etsi.org.

Specifications

Modernising the way packets are forwarded

One of the main drivers for the formation of ISG NGP was operators' need to make more efficient use of spectrum. While New Radio allows more bits to be carried, by some estimates half of those bits are unnecessary overhead. NGP is investigating how these overheads can be reduced, while at the same time providing the kind of performance (such as lower latency) that the new services proposed for 5G will need.

When the TCP/IP protocol suite was devised, around 1980, memory was a scarce resource so switches and routers kept as little information as possible; all the information needed to route a packet to its destination had to be in the packet header. Thus each packet was a separate event, like a letter arriving at a postal sorting office. However, in practice most packets are part of a sequence or "flow", and different kinds of flow need a different service. For instance, in a live audio or video stream packets are sent at regular intervals, and need to arrive at their destination at regular intervals; this can be assured by reserving resources along the route the packets will follow. Other kinds of flow consist of packets that are sent at unpredictable intervals, so reserving resources is not appropriate; these flows simply need the packets to arrive as soon as possible.

Memory sizes have increased by a factor of about a million, so information about each flow can now be stored in the network, and technologies such as SDN are used to control the kind of service each flow receives. But packets still have IP headers, and often Ethernet headers as well.

It would be much simpler and cleaner for the packet header to simply contain an index to the entry in the routing table, thus identifying the flow direcly, along with per-packet information such as the data length. Instead of the DNS look-up, the application can ask for a route to the domain name, service, content, etc, it requires, and can specify the level of service required. Information which is currently conveyed by protocols such as SDP can be carried in the same messages. New types of service (different priority mechanisms, perhaps) can be supported by new fields in the routing table, without needing to change the format of packet headers. New forms of address (such as content-centric) can be supported with nothing more than a software update in the control plane.

A system using these methods has been prototyped and is described in clause 5 of GR 003, available from the Specifications tab.

Achieving the lowest latency for delay-sensitive traffic

Almost every packet on a digital network is part of a "flow", a sequence of packets from the same source to the same destination. These flows are of two types:

We can think of the former as "AV" flows and of the latter as "IT" flows. For many applications, AV flows are sensitive to "latency", which is the time between a packet being transmitted by the sender and received at its destination; in a phone call, for example, longer delays make it difficult to have a natural conversation. New applications proposed for 5G, such as those involving augmented or virtual reality, or tactile feedback, will have even more severe requirements. For IT flows, if latency is important at all it will be the average over time that matters, whereas for AV flows it is the delay for the slowest packet.

Current-generation networks were originally designed as IT networks, carrying IT flows, and have had various features added to assist AV flows, which increase complexity but still do not provide the best service for these flows.

For NGP we propose to have separate services for AV and IT flows; on communication links, the two services are multiplexed together with the AV service taking the space it needs when it needs it and the IT service using all of the remaining capacity. This would have been expensive to implement on 1980s hardware, but is easy to provide in current-generation logic. The IT service uses label routing as described in the previous blog post; the AV service uses synchronization to achieve the lowest possible latency, as described below.

We define a "slot" as an opportunity for an AV packet to be transmitted. Each slot is allocated to a specific flow (with free slots being allocated to a "null" flow), so each flow has its own set of slots and the service it gets can't be affected by traffic on other flows; thus, no shaping or policing is needed. Packets don't need labels, because they can be identified by the slot in which they arrive. If the slots on different links are phase-locked (and in the prototype implementation that was found to be really easy to do) the delay through each switch, and hence the flow's latency through the network, is fixed.

Forwarding can be done by simply copying all incoming AV packets (or rather, the contents of all incoming slots, from all ports on the switch) to a buffer where they stay for a few microseconds before being overwritten; each output has a routing table which tells it from where in the buffer to take the packet to fill each slot. Thus a flow can be multicast simply by setting more than one output to transmit it.

The original proposal was to allow slots to be of any size from a few bytes (for packets carrying a single audio sample) up to about 4KB (for video), but in practice the minimum size is the width of the buffer (which needs to be quite wide to achieve the necessary throughput) and the maximum needs to be quite small because fragmentation of the space on a link (when a few flows have been routed) could make it impossible to route a flow that needs a large slot. A fixed size of 64 bytes was therefore chosen; using a fixed size means that there is no need for control plane protocols to signal where the slots begin. That is, of course, not very different from the size of an ATM cell, but unlike in ATM any unused space is not wasted but made available to the IT service.

The AV service is very simple and efficient to implement, and can be used for any traffic that needs guaranteed throughput. It provides very low latency as standard; the buffering delay is less than 15 microseconds per hop. For "variable bit rate" traffic, such as constant-quality compressed media, the flow can simply be set up to carry the peak bandwidth, and any unused capacity will be available for the IT service.

Because the AV service can be used for any traffic that has requirements on throughput or latency, the IT service can be a purely best-effort service, without any provision for prioritising one flow over another, although if such facilities are required (to support slicing, perhaps) they can be implemented in the same way as in current networks.

The AV service may also be the best way to transfer large files. The main purpose of protocols such as TCP is to control the rate of transmission and to request retransmission of packets that have been discarded because of buffer overflow. With the AV service, the transmission rate is fixed and packets will not be discarded, so a much simpler protocol which merely checks for transmission errors can be used. The flow only needs to be set up in one direction in the data plane, because any request for retransmission can be sent via the control plane; usually all that will be needed is to indicate success when clearing the flow down. This process can also be used to multicast a file to a large number of recipients, for instance when distributing a software update.

For more details see clause 5.3.4 of GR 003, also available from the Specifications tab.

Migration made easy

IPv6 is finally beginning to be adopted, more than two decades after its specification was published in RFC 1883. Why did it take so long? And how will NGP avoid the same problems?

Internet Protocol (IP) is a "connectionless" technology, in which all the information necessary to deliver a packet to its destination must be in the packet header. This includes the destination address and the address to be used for sending a reply, as well as other information regarding the service the packet should experience. The format of this information has to be the same throughout the system, so that it can be understood by any switching equipment the packet might pass through. IPv4 and IPv6 use different formats, so if support for IPv6 is to be added to an IPv4 network, all equipment in the network must be updated so it can process IPv6 headers. Only when that has been done can IPv6 be used.

When IP was first specified, packet headers were processed at each switching point by software running in a general-purpose computer. Since then, transmission speeds have increased by more than processing speeds, so more of the processing of headers has to be done in hardware. Technologies such as Software Defined Networking (SDN) recognize that most packets are part of a "flow" such as an audio or video stream or an exchange of information between a browser and a web site; decisions about how each flow should be forwarded are made by software and loaded into a "routing table" at each of the switching points. The hardware in the switch reads the packet header and searches the routing table to find the entry that matches it.

Thus, adding support for IPv6 addresses doesn't just need a software upgrade, it needs new hardware that is able to read IPv6 headers in addition to the existing IPv4 hardware.

GS NGP 013 specifies a system (with the working title Flexilink) in which the packet header carries a "label", which is an index into the routing table, and all other information is carried in control plane messages and is thus sent once for each flow instead of in every packet: the ultimate in header compression. Routing table entries in each switch only need to show the action to be performed by that switch, typically the output port number and the label for the next hop. Supporting a new form of addressing (such as content-centric, or using a domain name directly as an address) only needs a software update to the control elements, and no change to the hardware. The packet format can be different for different kinds of link, for instance having a larger field for the label on links that can carry more flows, but this only affects equipment designed for that kind of link, which will in any case have hardware that is specific to that link type.

Any part of an IP network can be replaced by Flexilink without affecting the rest of the network. Depending on requirements, IP packets (either version) can be carried with their headers included, in the same way as over MPLS, or the headers can be stripped on entry and added back on exit. In the latter case the routing table has to hold the necessary information to construct the IP header, but if the IP network would be doing address translation a similar amount of information would need to be held in any case.

Thus with Flexilink a single hardware implementation is able to support multiple addressing schemes including both IPv4 and IPv6.